前幾天，我一直在寫測試、失敗、驗證，以及系統為什麼不能因為「看起來成功」就直接宣布成功。

但做到後面，我開始遇到一個更大的問題：

如果一個 AI 系統真的會從過去的經驗中學習，那它是不是有一天也會把自己改壞？

這其實是我在做 ARCI（Autonomous Resilient Communication Intelligence）時，越來越在意的一件事。

因為我真正想做的，從來不只是一個「會回答問題的 AI」。

我想做的是一個在環境改變、通訊失效、資源受限，甚至部分系統故障的情況下，仍然能重新判斷、選擇策略、執行、確認結果，必要時重新規劃的系統。

但只要繼續往這條路走，就一定會碰到一個問題：

如果系統會學習，那誰來驗證它學到的是對的？

會學習，不代表可以直接改變自己

很多人想到「自主學習 AI」，第一個畫面可能是：

AI 發現自己哪裡做不好，然後自己修改策略，下一次就變得更聰明。

聽起來非常合理。

但工程上，我反而覺得這是一件很危險的事。

假設今天系統遇到一次特殊情況。

某個策略剛好成功了。

如果 AI 因此判斷：

「這個方法很好，以後都這樣做。」

然後直接修改正式系統的行為，那其實只需要一次偶然成功，就可能讓整個系統開始偏離原本的安全邊界。

更麻煩的是，這種錯誤不一定會立刻爆炸。

它可能只是慢慢累積。

第一次差一點。

第二次再偏一點。

到了第十次，系統已經和最初設計的版本完全不同。

所以我最後決定：

ARCI 可以學習，但不能因為「學到了什麼」就直接改 production。

這兩件事情必須拆開。

我想要的不是 Self-Modifying AI

我目前對 ARCI 長期學習的想法，大致可以拆成五個階段：

Observe → Learn → Propose → Validate → Promote

也就是：

觀察。

學習。

提出候選策略。

驗證。

最後才允許正式升級。

其中最重要的其實不是 Learn。

而是後面的三個字：

Propose、Validate、Promote。

因為「學到一個東西」和「允許這個東西改變系統」應該是兩個完全不同的權限。

1. Observe：先記住發生了什麼

假設 ARCI 正在處理一個災害通訊情境。

原本最適合的通訊路徑可能是：

5G → Wi-Fi → 衛星

但是某一次災害中，5G 基地台失效，Wi-Fi 又因為停電中斷，最後反而是另一組低頻寬通訊方式成功把最重要的訊息送出去。

這件事情值得記住。

但是「值得記住」不代表「以後都應該這樣做」。

所以第一步只是留下經驗。

例如：

• 當時環境是什麼？
• 哪些資源可以使用？
• 哪些資源失效？
• 系統選了什麼策略？
• 最後成功還是失敗？
• 花了多少時間？
• 中間重新規劃過幾次？

也就是先把一次任務變成可以分析的經驗。

2. Learn：從很多次經驗找出模式

只有一筆成功案例，其實幾乎不能證明什麼。

但是如果未來累積到數百、數千次任務，就可能開始看到一些規律。

例如：

某類環境下，策略 A 的成功率一直高於策略 B。

或者：

某種訊號品質下降到一個程度之後，繼續等待恢復的效益開始低於直接切換路徑。

這時 AI 才有資格說：

「我好像發現了一個值得研究的模式。」

注意，我刻意不是寫：

「我找到更好的策略。」

因為這時仍然只是 candidate。

候選。

不是答案。

3. Propose：只能提出建議，不能直接修改

這是我認為很重要的一層。

假設系統真的從歷史資料發現：

在某些情況下，把策略 B 的優先權提高，可能會比目前策略更好。

它不能直接把：

priority(B) = 0.4

改成：

priority(B) = 0.8

然後下一次正式任務就直接使用。

它應該產生的是一個：

Upgrade Candidate

也就是「升級候選」。

裡面必須回答：

為什麼要改？

根據哪些歷史結果？

影響哪些決策？

預期改善什麼？

可能造成什麼風險？

如果失敗，怎麼回復？

這時 AI 比較像研究員，而不是管理員。

它可以提出假說。

但不能自己批准自己的假說。

4. Validate：讓候選策略接受測試

這也是我最近一直在 ARCI 裡強調的概念：

成功不能靠感覺。

新的策略至少必須重新面對：

既有測試。

歷史案例。

失敗案例。

極端條件。

deterministic replay。

以及原本已經建立的安全限制。

如果新的策略在某些情況表現比較好，卻讓另一批重要情境退化，那它不應該被稱為「升級」。

它只是交換了問題。

所以：

Learning 產生的是 hypothesis，而 validation 才產生 evidence。

我覺得這是我最近做這個作品之後，越來越確定的一件事情。

5. Promote：最後才允許進入正式系統

如果候選策略真的通過所有必要驗證，它才可能進入 Promote。

也就是：

從候選版本變成正式版本。

而且即使到了這一步，我仍然希望它保留完整的：

• 版本
• 來源
• 原因
• 驗證結果
• 前一版本
• rollback 能力

因為一個可以自主進化的系統，如果最後回答不了：

「你為什麼變成現在這個樣子？」

那它其實只是變得越來越難控制而已。

真正困難的不是讓 AI 更聰明

做到現在，我開始覺得：

讓 AI 做更多事情，其實不是最困難的部分。

讓模型產生建議。

不難。

讓模型分析歷史紀錄。

也不是最難。

甚至讓模型自己提出新的策略，都已經逐漸變成可以做到的事情。

真正困難的是：

怎麼限制它。

什麼時候可以學？

什麼可以學？

學到的東西能影響哪裡？

誰負責驗證？

什麼證據才算通過？

如果升級失敗怎麼退回？

這些問題，可能比「模型到底多聰明」還重要。

ARCI 的 Autonomous，對我來說不是「完全自由」

ARCI 的 A 是 Autonomous。

但我現在對 Autonomous 的理解，和剛開始做這個作品的時候已經有點不同。

以前我可能會覺得：

自主就是盡量不要需要人。

現在我反而覺得：

自主應該是在清楚的邊界內，允許系統自己完成越來越多事情。

真正可靠的 autonomous system，不應該是一個想做什麼就做什麼的系統。

而是一個知道：

自己可以決定什麼，

不能決定什麼，

什麼時候必須停下來，

以及什麼時候必須證明自己真的做對了的系統。

所以第五天，我沒有再增加一個功能

今天沒有新的華麗畫面。

也沒有新的 Demo。

我反而花時間重新整理一個我認為會影響 ARCI 很久的問題：

如果未來真的讓它具備長期學習能力，我希望它怎麼學？

目前我的答案是：

它可以觀察。

可以累積經驗。

可以提出新的策略。

甚至可以找到比人原本設計更好的做法。

但是它不能只因為「自己覺得比較好」，就直接改變正式系統。

在真正升級之前，它仍然必須通過驗證。

所以如果要用一句話總結我目前對 ARCI 長期自主學習的想法，大概會是：

我不是想做一個會自己改自己的 AI，而是想做一個能替自己的改變提出證據的 AI。

這可能也是我目前最想繼續往下做的方向。

Day 05，完成。